Internet Info 1994 March

home *** CD-ROM | disk | FTP | other *** search

/ Internet Info 1994 March / Internet Info CD-ROM (Walnut Creek) (March 1994).iso / inet / internet-drafts / draft-ietf-bgp-bgp4ospf-interact-00.txt < prev next >

Wrap

Text File | 1993-03-03 | 41.3 KB | 1,069 lines

Network Working Group K. Varadhan Request for Comments: DRAFT OARnet September 15, 1992 BGP4 OSPF Interaction Table of Contents 1. Introduction .................................................... 1 2. Reachability Information Exchange ............................... 3 2.1. Exporting OSPF information into BGP ........................... 3 2.2. Importing BGP information into OSPF ........................... 4 3. BGP Identifier and OSPF router ID ............................... 5 4. Setting OSPF tags, BGP ORIGIN and AS_PATH attributes ............ 6 4.1. Semantics of the characteristics bits ......................... 8 4.2. Configuration parameters for setting the OSPF tag ............. 9 4.3. Manually configured tags ...................................... 10 4.4. Automatically generated tags .................................. 11 4.4.1. Destinations with incomplete path information, PathLength =0 . 11 4.4.2. Destinations with incomplete path information, PathLength =1 . 11 4.4.3. Destinations with incomplete path information, PathLength >=1 12 4.4.4. Destinations with complete path information, PathLength =0 ... 12 4.4.5. Destinations with complete path information, PathLength =1 ... 13 4.4.6. Destinations with complete path information, PathLength >=1 .. 14 4.5. Miscellaneous tag settings .................................... 14 4.6. Summary of the TagType field setting .......................... 15 5. Setting OSPF Forwarding Address and BGP NEXT_HOP attribute ...... 15 6. Changes from the BGP 3 - OSPF interactions document ............. 16 7. Security Considerations ......................................... 17 8. Acknowledgements ................................................ 17 9. Bibliography .................................................... 17 10. Author's Address ............................................... 18 Status of this Memo This document is an Internet Draft. Internet Drafts are working documents of the Internet Engineering Task Force (IETF), its Areas, and its Working Groups. Note that other groups may also distribute working documents as Internet Drafts. Internet Drafts are draft documents valid for a maximum of six months. Internet Drafts may be updated, replaced, or obsoleted by other documents at any time. It is not appropriate to use Internet Drafts as reference material or to cite them other than as a ``working draft'' or ``work in progress.'' Please check the I-D abstract listing contained in each Internet Varadhan [Page 1] INTERNET DRAFT (Expires March 15, 1993) September 92 Draft directory to learn the current status of this or any other Internet Draft. Abstract This memo defines the various criteria to be used when designing an Autonomous System Border Routers (ASBR) that will run BGP4 with other ASBRs external to the AS and OSPF as its IGP. 1. Introduction This document defines the various criteria to be used when designing an Autonomous System Border Routers (ASBR) that will run BGP4[BGP-4] with other ASBRs external to the AS, and OSPF[RFC1247] as its IGP. All future references of BGP in this document will refer to BGP version 4, as defined in [BGP-4]. This document defines how the following fields in OSPF and attributes in BGP are to be set when interfacing between BGP and OSPF at an ASBR: BGP MULTI_EXIT_DISC vs. OSPF cost and type BGP ORIGIN and AS_PATH vs. OSPF tag BGP NEXT_HOP vs. OSPF Forwarding Address BGP LOCAL_PREF vs. OSPF cost For a more general treatise on routing and route exchange problems, please refer to [ROUTE-LEAKING] and [NEXT-HOP] by Philip Almquist. This document uses the two terms ``Autonomous System'' and ``Routing Domain.'' The definitions for the two are below: The term Autonomous System is the same as is used in the BGP RFC[RFC1267], given below: ``The use of the term Autonomous System here stresses the fact that, even when multiple IGPs and metrics are used, the administration of an AS appears to other ASs to have a single coherent interior routing plan and presents a consistent picture of what destinations are reachable through it. From the standpoint of exterior routing, an AS can be viewed as monolithic: reachability to destinations directly connected to the AS must be equivalent from all border gateways of the AS.'' The term Routing Domain was first used in [ROUTE-LEAKING] and is given below: Varadhan [Page 2] INTERNET DRAFT (Expires March 15, 1993) September 92 ``A Routing Domain is a collection of routers which coordinate their routing knowledge using a single (instance of) a routing protocol.'' By definition, a Routing Domain forms a single Autonomous System, but an Autonomous System may be composed of a collection of Routing Domains. BGP and OSPF have the concept of a set of reachable destinations. | This set is called NLRI or Network Layer Reachability Information. | The set can be represented either as an IP address prefix, or an | address, mask pair. Note that if the mask is contiguous in the | latter, then the two representations are equivalent. In this | document, we use the term ``address/mask pair'' in the context of | OSPF, and ``destination'' or ``set of reachable destinations'' in | the context of BGP. This document follows the conventions embodied in the Host Requirements RFCs [RFC1122, RFC1123], when using the terms "MUST", "SHOULD," and "MAY" for the various requirements. 2. Reachability Information Exchange This section discusses the constraints that must be met to exchange the set of reachable destinations between an external BGP session with a peer from another AS and internal OSPF address/mask pairs. 2.1. Exporting OSPF information into BGP 1. The administrator MUST be able to selectively export | address/mask pairs into BGP via an appropriate filter | mechanism. | This filter mechanism MUST support such control with the | granularity of an address/mask pair. | This filter mechanism will be the primary method of | aggregation of OSPF internal and type 1 and type 2 external | routes within the AS into BGP. | Additionally, the administrator MUST be able to filter based on the OSPF tag and the various sub-fields of the OSPF tag. The settings of the tag and the sub-fields are defined in section 4 in more detail. Varadhan [Page 3] INTERNET DRAFT (Expires March 15, 1993) September 92 o The default MUST be to export no routes from OSPF into BGP. A single configuration parameter MUST permit all OSPF inter-area and intra-area address/mask pairs to be exported into BGP. OSPF external address/mask pairs of type 1 and type 2 MUST never be exported into BGP unless they are explicitly configured. 2. An address/mask pair having a non-contiguous mask MUST not be | exported to BGP. | 3. When configured to export an address/mask pair from OSPF into | BGP, the ASBR MAY advertise the route containing the set of | reachable destinations via BGP as soon as at least one of the | destinations in the address/mask pair is determined to be | reachable via OSPF; it MUST stop advertising the route | containing the set of reachable destinations when none of the | destinations in the address/mask pair is reachable via OSPF. | 4. The network administrator MUST be able to statically | configure the BGP attribute MULTI_EXIT_DISC attribute to be | used for any route. | o The default MUST be to omit the MULTI_EXIT_DISC in the | route advertised via BGP[BGP-4]. | 5. An implementation of BGP and OSPF on an ASBR MUST have a mechanism to set up a minimum amount of time that must elapse between the learning of a new address/mask pair via OSPF and subsequent advertisement of the address/mask pair via BGP to the external neighbours. o The default value for this setting MUST be 0, indicating that the address/mask pair is to be advertised to the neighbour BGP peers instantly. Note that [BGP-4] mandates a mechanism to dampen the inbound advertisements from adjacent neighbours. See the variable MinRouteAdvertisementInterval in section 9.2.3.1. 2.2. Importing BGP information into OSPF 1. BGP implementations SHOULD allow an AS to control announcements of BGP-learned set of reachable destinations into OSPF. Implementations SHOULD support such control with the granularity of a single destination. Implementations Varadhan [Page 4] INTERNET DRAFT (Expires March 15, 1993) September 92 SHOULD also support such control with the granularity of an autonomous system, where the autonomous system may be either the autonomous system that originated the information or the autonomous system that advertised the information to the local system (adjacent autonomous system). o The default MUST be to import nothing from BGP into OSPF. Administrators must configure every destination they wish to import. A configuration parameter MAY allow an administrator to configure an ASBR to import all the set of reachable destinations from BGP into the OSPF routing domain. 2. The administrator MUST be able to configure the OSPF cost and the OSPF metric type of every destination imported into OSPF. o The OSPF cost MUST default to the LOCAL_PREF value; the | OSPF metric type MUST default to type 2. | 3. Information learned via BGP from peers within the same AS MUST not be imported into OSPF. 4. The ASBR MUST never generate a default destination into the OSPF routing domain unless explicitly configured to do so. A default destination is a set of all possible destinations. By convention, it is represented as a prefix 0 length or a mask of all zeroes. A possible criterion for generating default into an IGP is to allow the administrator to specify a set of (set of reachable destinations, AS_PATH, default cost, default type) tuples. If the ASBR learns of at least one of the destinations in the set of reachable destinations, with the corresponding AS_PATH, then it generates a default destination into the OSPF routing domain, with the appropriate cost and type. The lowest cost route will then be injected into the OSPF routing domain. This is the recommended method for originating default destinations in the OSPF routing domain. | 5. Note that [RFC1247] requires the network number to be used as | the Link State ID. This will produce a conflict if the ASBR | tries to import two destinations, differing only in their | prefix length. An implementation conforming to [RFC1247] | MUST, in this case, drop the more specific route, i.e. the | Varadhan [Page 5] INTERNET DRAFT (Expires March 15, 1993) September 92 route corresponding to the longer prefix in the reachability | information. | Note that the OSPF WG is working on revising [RFC1247]. The | revised version will incorporate hooks to handle the | conflict. 3. BGP Identifier and OSPF router ID The BGP identifier MUST be the same as the OSPF router id at all times that the router is up. Note that [BGP-4] requires that the BGP | identifier be an address assigned to the BGP speaker. This characteristic is required for two reasons. i Consider the scenario in which 3 ASBRs, RT1, RT2, and RT3, belong to the same autonomous system. +-----+ | RT3 | +-----+ | Autonomous System running OSPF / \ +-----+ +-----+ | RT1 | | RT2 | +-----+ +-----+ Both RT1 and RT2 can reach an external destination X and import this information into the OSPF routing domain. RT3 is advertising this information about destination X to other external BGP speakers. RT3 must use the OSPF router ID to determine whether it is using RT1 or RT2 to forward packets to destination X and hence build the correct AS_PATH to advertise to other external speakers. More precisely, RT3 MUST determine which ASBR it is using to | reach destination X by matching the OSPF router ID for its | route to destination X with the BGP identifier of one of the | ASBRs; it MAY then generate the corresponding network layer | reachability information for further advertisement to external | Varadhan [Page 6] INTERNET DRAFT (Expires March 15, 1993) September 92 BGP peers. ii It will be convenient for the network administrator looking at an ASBR to correlate different BGP and OSPF information based on the identifier. 4. Setting OSPF tags, BGP ORIGIN and AS_PATH attributes The OSPF external route tag is a ``32-bit field attached to each external route . . . It may be used to communicate information between AS boundary routers; the precise nature of such information is outside the scope of [the] specification.''[RFC1247] OSPF imports information from various routing protocols at all its ASBRs. In some instances, it is possible to use protocols other than EGP or BGP across autonomous systems. It is important, in BGP, to differentiate between reachable destinations that are external to the OSPF routing domain but must be considered internal to the AS, as opposed to reachable destinations that are external to the AS. Reachable destinations that are internal to the AS and that may or may not be external to the OSPF routing domain will not come to the various BGP speakers from other BGP speakers within the same autonomous system via BGP. Therefore, ASBRs running BGP must have knowledge of this class of reachable destinations so that they can advertise these destinations to the various external AS without waiting for BGP updates from other BGP speakers within the same autonomous system about these destinations. Additionally, in the specific instance of an AS intermixing routers running EGP and BGP as external gateway routing protocols, using OSPF as an IGP, then within the autonomous system, it may not be necessary to run BGP with every ASBR running EGP and not running BGP, if this information can be carried in the OSPF tag field. We use the external route tag field in OSPF to intelligently set the ORIGIN and AS_PATH attributes in BGP. Both the ORIGIN and AS_PATH attributes are well-known, mandatory attributes in BGP. The exact mechanism for setting the tags is defined below. The tag is broken up into sub-fields shown below. The various sub- fields specify the characteristics of the set of reachable destinations imported into the OSPF routing domain. The high bit of the OSPF tag is known as the ``Automatic'' bit. When this bit is set to 1, the following sub-fields apply: Varadhan [Page 7] INTERNET DRAFT (Expires March 15, 1993) September 92 0 0 0 0 0 0 0 0 0 0 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |a|c|p l| ArbitraryTag | AutonomousSystem | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ a is 1 bit called the Automatic bit, indicating that the Completeness and PathLength bits have been generated automatically by a router. The meaning of this characteristic and its setting are defined below. c is 1 bit of Completeness information. The meaning of this characteristic and its settings are defined below. pl are 2 bits of PathLength information. The meaning of this characteristic and its setting are defined below. ArbitraryTag is 12 bits of tag information, which defaults to 0 but can be configured to anything else. AutonomousSystem (or ``AS'') is 16 bits, indicating the AS number corresponding to the set of reachable destinations, 0 if the set of reachable destinations is to be considered as part of the local AS. local_AS The term `local_AS' refers to the AS number of the local OSPF routing domain. next_hop_AS `next_hop_AS' refers to the AS number of an external BGP peer. When the Automatic bit is set to 0, the following sub-fields apply: 0 0 0 0 0 0 0 0 0 0 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |a| LocalInfo | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ a is 1 bit called the Automatic bit, set to 0. LocalInfo Varadhan [Page 8] INTERNET DRAFT (Expires March 15, 1993) September 92 is 31 bits of an arbitrary value, manually configured by the network administrator. The format of the tag for various values of the characteristics bits is defined below. 4.1. Semantics of the characteristics bits The Completeness and PathLength characteristics bits define the characteristic of the set of reachable destinations imported into OSPF from other ASBRs in the autonomous system. This setting is then used to set the ORIGIN and NEXT_HOP attributes when re- exporting these reachable destinations to an external BGP speaker. o The Automatic characteristic bit is set when the Completeness and PathLength characteristics bits are automatically set by a border router. For backward compatibility, the Automatic bit must default to 0 and the network administrator must have a mechanism to enable automatic tag generation. Nothing must be inferred about the characteristics of the OSPF address/mask pair from the tag bits, unless the tag has been automatically generated. o The Completeness characteristic bit is set when the source of the incoming route is known precisely, for instance, from an IGP within the local autonomous system or EGP at one of the autonomous system's boundaries. It refers to the status of the path information carried by the routing protocol. o The PathLength characteristic sub-field is set depending on the length of the AS_PATH that the protocol could have carried when importing the reachability information into the OSPF routing domain. The length bits will indicate whether the AS_PATH attribute for the length is zero, one, or greater than one. Reachable destinations imported from an IGP will usually have an AS_PATH of length of 0, reachable destinations imported from an EGP will have an AS_PATH of length 1, BGP and routing protocols that support complete path information, either as AS_PATHs or routing domain paths, will indicate a path greater than 1. The OSPF tag is not wide enough to carry path information about reachable destinations that have an associated PathLength greater than one. Path information about these Varadhan [Page 9] INTERNET DRAFT (Expires March 15, 1993) September 92 destinations will have to be carried via BGP to other ASBRs with the same autonomous system. Such destinations must not be exported from OSPF into BGP. In the following sections, the code YES will have value 1, and the | code NO will have value 0. 4.2. Configuration parameters for setting the OSPF tag o There MUST be a mechanism to enable automatic generation of the tag characteristic bits. o Configuration of an ASBR running OSPF MUST include the capability to associate a tag value, for the ArbitraryTag, or LocalInfo sub-field of the OSPF tag, with each instance of a routing protocol. o Configuration of an ASBR running OSPF MUST include the capability to associate an AS number with each instance of a routing protocol. Associating an AS number with an instance of an IGP is equivalent to flagging those set of reachable destinations imported from the IGP to be external destinations outside the local autonomous system. Specifically, when the IGP is RIP[RFC1058], it SHOULD be possible to associate a tag and/or an AS number with every interface running RIP on the ASBR. Varadhan [Page 10] INTERNET DRAFT (Expires March 15, 1993) September 92 4.3. Manually configured tags 0 0 0 0 0 0 0 0 0 0 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0| LocalInfo | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ This tag setting corresponds to the administrator manually setting the tag bits. Nothing MUST inferred about the characteristics of the set of reachable destinations corresponding to this tag setting. For backward compatibility with existing implementations of OSPF currently deployed in the field, this MUST be the default setting for importing destinations into the OSPF routing domain. There MUST be a mechanism to enable automatic tag generation for imported destinations. The OSPF tag to BGP attribute mappings for these reachable destinations MUST be Automatic=NO, LocalInfo=Arbitrary_Value => ORIGIN=<INCOMPLETE>, AS_PATH=<local_AS> 4.4. Automatically generated tags 4.4.1. Destinations with incomplete path information, PathLength = 0 0 0 0 0 0 0 0 0 0 0 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |1|0|0|0| ArbitraryTag | AutonomousSystem | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ These are reachable destinations imported from routing protocols with incomplete path information and cannot or may not carry the neighbour AS or AS path as part of the routing information. The OSPF tag to BGP attribute mappings for these destinations MUST be Automatic=YES, Completeness=NO, PathLength=00, AS=0 => ORIGIN=<EGP>, AS_PATH=<local_AS> Varadhan [Page 11] INTERNET DRAFT (Expires March 15, 1993) September 92 4.4.2. Destinations with incomplete path information, PathLength = 1 0 0 0 0 0 0 0 0 0 0 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |1|0|0|1| ArbitraryTag | AutonomousSystem | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ These are reachable destinations imported from routing protocols with incomplete path information. The neighbour AS is carried in the routing information. The OSPF tag to BGP attribute mappings for these destinations MUST be Automatic=YES, Completeness=NO, PathLength=01, AS=<next_hop_AS> => ORIGIN=<EGP>, AS_PATH=<local_AS, next_hop_AS> This setting SHOULD be used for importing reachable destinations from EGP into the OSPF routing domain. This setting MAY also be used when importing reachable destinations from BGP whose origin=<EGP> and AS_PATH=<next_hop_AS>; if the BGP learned route has no other transitive attributes, then its propagation via BGP to ASBRs internal to the autonomous system MAY be suppressed. Varadhan [Page 12] INTERNET DRAFT (Expires March 15, 1993) September 92 4.4.3. Destinations with incomplete path information, PathLength >= 1 0 0 0 0 0 0 0 0 0 0 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |1|0|1|0| ArbitraryTag | AutonomousSystem | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ These are reachable destinations imported from routing protocols with truncated path information. The OSPF tag to BGP attribute mappings for these destinations MUST be Automatic=YES, Completeness=NO, PathLength=10, AS=don't care These are imported by a border router, which is running BGP to a stub domain, and not running BGP to other ASBRs in the same autonomous system. This causes a truncation of the AS_PATH. These destinations MUST not be re-exported into BGP at another ASBR. 4.4.4. Destinations with complete path information, PathLength = 0 0 0 0 0 0 0 0 0 0 0 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |1|1|0|0| ArbitraryTag | AutonomousSystem | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ These are reachable destinations imported from routing protocols with either complete path information or are known to be complete through means other than that carried by the routing protocol. The OSPF tag to BGP attribute mappings for these destinations MUST be Automatic=YES, Completeness=YES, PathLength=00, AS=00 => ORIGIN=<EGP>, AS_PATH=<local_AS> This SHOULD be used for importing reachable destinations into OSPF from an IGP. Varadhan [Page 13] INTERNET DRAFT (Expires March 15, 1993) September 92 4.4.5. Destinations with complete path information, PathLength = 1 0 0 0 0 0 0 0 0 0 0 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |1|1|0|1| ArbitraryTag | AutonomousSystem | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ These are reachable destinations imported from routing protocols with either complete path information, or are known to be complete through means other than that carried by the routing protocol. The routing protocol also has additional information about the next hop AS the destination was learned from. The OSPF tag to BGP attribute mappings for these destination MUST be Automatic=YES, Completeness=YES, PathLength=01, AS=next_hop_AS => ORIGIN=<IGP>, AS_PATH=<local_AS, next_hop_AS> This setting SHOULD be used when the administrator explicitly associates an AS number with an instance of an IGP. This setting MAY also be used when importing reachable destinations from BGP whose origin=<IGP> and AS_PATH=<next_hop_AS>; if the BGP learned route has no other transitive attributes, then its propagation via BGP to other ASBRs internal to the autonomous system MAY be suppressed. Varadhan [Page 14] INTERNET DRAFT (Expires March 15, 1993) September 92 4.4.6. Destinations with complete path information, PathLength >=1 0 0 0 0 0 0 0 0 0 0 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |1|1|1|0| ArbitraryTag | AutonomousSystem | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ These are reachable destinations imported from routing protocols with complete path information and carry the AS path information as part of the routing information. The OSPF tag MUST be set to Automatic=YES, Completeness=YES, PathLength=10, AS=don't care These destinations MUST not be exported into BGP because these destinations are already imported from BGP into the OSPF RD. Hence, it is assumed that the BGP speaker will convey this information to other BGP speakers within the same autonomous system via BGP. As ASBR learning of such a destination MUST wait for the BGP update from its internal neighbours before advertising it to external BGP peers. Note that an implementation MAY import reachable destinations from BGP with a path length of 1 and no other transitive attributes directly into OSPF and not send these routes via BGP to ASBRs within the same autonomous system. In this situation, it MUST use tag settings corresponding to 4.4.2, or 4.4.5. 4.5. Miscellaneous tag settings 0 0 0 0 0 0 0 0 0 0 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |1|x|1|1| Reserved for future use | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The value of PathLength=11 is reserved during automatic tag generation. Routers must not generate such a tag when importing reachable destinations into the OSPF routing domain. ASBRs must ignore tags which indicate a PathLength=11. Varadhan [Page 15] INTERNET DRAFT (Expires March 15, 1993) September 92 4.6. Summary of the tag sub-field setting The following table summarizes the various combinations of automatic tag settings for the Completeness and PathLength sub- field of the OSPF tag and the default behaviour permitted for each setting. Completeness := 0 | 1 PathLength := 00 | 01 | 10 | 1 ORIGIN := <INCOMPLETE> | <IGP> | <EGP> AS_PATH := valid AS path settings as defined in BGP [BGP-4] PathLength ==> 00 01 10 11 Completeness || +-------------------------------------------------------------------- vv | = NO | <EGP> <EGP> never export reserved | <local_AS> <local_AS,next_hop_AS> | = YES | <IGP> <IGP> out of band reserved | <local_AS> <local_AS,next_hop_AS> | The "out of band" in the table above implies that OSPF will not be able to carry everything that BGP needs in its routing information. Therefore, some other means must be found to carry this information. In BGP, this is done by running BGP to other ASBRs within the same autonomous system. 5. Setting OSPF Forwarding Address and BGP NEXT_HOP attribute Forwarding addresses are used to avoid extra hops between multiple routers that share a common network and that speak different routing protocols with each other on the common network. | Both BGP and OSPF have equivalents of forwarding addresses. In BGP, the NEXT_HOP attribute is a well-known, mandatory attribute. OSPF has a Forwarding address field. We will discuss how these are to be filled in various situations. Varadhan [Page 16] INTERNET DRAFT (Expires March 15, 1993) September 92 Consider the 4 router situation below: RT1 and RT2 are in one autonomous system, RT3 and RT4 are in another. RT1 and RT3 are talking BGP with each other. RT3 and RT4 are talking OSPF with each other. +-----+ +-----+ | RT1 | | RT2 | +-----+ +-----+ | | common network ---+-----------------------+-------------------------- <BGP> | | +-----+ <OSPF> +-----+ | RT3 | | RT4 | +-----+ +-----+ - Importing a reachable destination into OSPF: | When importing a destination from BGP into OSPF, RT3 MUST | always fill the OSPF Forwarding Address with the BGP NEXT_HOP | attribute for the destination. | - Exporting a reachable destination into BGP: | When exporting set of reachable destinations internal to the | OSPF routing domain from OSPF to BGP, if all the destinations | in the set of reachable destinations are through RT4, then RT3 | MAY fill the NEXT_HOP attribute for the set of reachable | destinations with the address of RT4. This is to avoid | requiring packets to take an extra hop through RT3 when | traversing the AS boundary. This is similar to the concept of | indirect neighbour support in EGP[RFC888, RFC827]. | 6. Changes from the BGP 3 - OSPF interactions document | o The use of the term "route" has attained a more complicated | structure in BGP 4. This document follows the constraint in | the manner shown below: | - The term "set of reachable destinations" is called a NLRI | in [BGP-4]. | - The term "route" in the BGP context refers to a set of | reachable destinations, and the associated attributes for | the set. | - The term "route" in the OSPF context refers to the set of | reachable destinations, and the cost and the type to | Varadhan [Page 17] INTERNET DRAFT (Expires March 15, 1993) September 92 reach destinations. This is to keep the definitions | consistent in the document. | o The notion of exchanging reachability information between BGP | 4 and OSPF has been updated to handle variable length net mask | information. | o The previous term INTER_AS_METRIC in BGP 3 has now been | changed to MULTI_EXIT_DISC. | o The default metric to be used for importing BGP information | into the OSPF RD is now the LOCAL_PREF attribute, instead of a | constant value. | o BGP 4 requires that the BGP identifier be an address assigned | to the BGP speaker. This is dealt with in section 3. | o Section 5 on setting NEXT_HOP attributes and Forwarding | Address fields has been updated to account for variable length | net information. | o This section, 6, has been added. | 7. Security Considerations Security considerations are not discussed in this memo. 8. Acknowledgements I would like to thank Yakov Rekhter (IBM Corporation), Jeff Honig (Cornell University), John Moy (Proteon, Inc.), Tony Li (cisco Systems), Rob Coltun (Consultant), Dennis Ferguson (ANS, Inc.), and Phil Almquist (Consultant) for their help and suggestions in writing this document, without which I could not have written this document. I would also like to thank them for giving me the opportunity to write this document, and putting up with my muddlements through various phases of this document. I would also like to thank the countless number of people from the OSPF and BGP working groups who have offered numerous suggestions and comments on the different stages of this document. Thanks also to Bob Braden (ISI), whose suggestions on the earlier BGP-OSPF document, [RFC1364] were useful even for this one, and have been carried through. Varadhan [Page 18] INTERNET DRAFT (Expires March 15, 1993) September 92 9. Bibliography [RFC827] Rosen, Eric C., ``Exterior Gateway Protocol (EGP)'', October 1982. [RFC888] Seamonson, Linda J.; and Rosen, Eric C., ``'STUB' Exterior Gateway Protocol'', January 1984. [RFC1058] Hedrick, Charles, L., ``Routing Information Protocol'', June 1988. [RFC1122] Braden, R.T., ed., ``Requirements for Internet hosts - communication layers'', October 1989. [RFC1123] Braden, R.T., ed., ``Requirements for Internet hosts - application and support'', October 1989. [RFC1247] Moy, John, ``The OSPF Specification Version 2'', January 1991. [RFC1338] Fuller, Vince; Li, Tony; Yu, Jessica; Varadhan, Kannan, ``Supernetting: an Address Assignment and Aggregation Strategy'', June 1992. [ROUTE-LEAKING] Almquist, Philip, ``Ruminations on Route Leaking'', in preparation. [NEXT-HOP] Almquist, Philip, ``Ruminations on the Next Hop'', in preparation. [BGP-4] Rekhter, Yakov; and Li, Tony, Editors ``A Border Gateway Protocol 4 (BGP-4)'', in preparation. [RFC1364] Varadhan, Kannan; ``BGP OSPF Interaction'', in preparation. 10. Author's Address: Kannan Varadhan Internet Engineer, OARnet, 1224, Kinnear Road, Columbus, OH 43212-1136. email: kannan@oar.net Varadhan [Page 19] ----- -=- Kannan Varadhan, 1224, Kinnear Road, +1 614 292 4137 Internet Engineer (OARnet) Columbus, OH 43212 +1 614 292 7168 (FAX)